RRAS Inbound VPNs, cannot ping remote networks "No Resources"
I have a standalone monitoring server running Windows 2008 (w/SP2). I only have RRAS enabled so far. A bunch of remote routers VPN in using PPTP. Behind these routers are one or more subnets. For example: Server Name = monitor Server IP = 55.66.77.88 VPN IP = 10.1.1.1 Router 1 WAN IP = 99.88.77.66 Router 1 LAN IP = 192.168.40.1/24 Router 1 VPN IP = 10.1.1.2 Router 1 VPN Username = monitor\router1 Router 2 WAN IP = 100.99.88.77 Router 2 LAN IP = 192.168.100.1/24, 192.168.15.1/24 Router 2 VPN IP = 10.1.1.3 Router 2 VPN Username = monitor\router2 If I simply configure a Dial-In User account on the server, then wait until a VPN connection is established and manually configure the routes, everything works fine. I can ping all the devices on the LAN sides of both routers (192.168.40.xxx, 192.168.100.xxx, 192.168.15.xxx). But this requires manually adding static routes each time the VPN connection is re-established, so I need to automate the addition of these routes. I opened the Computer Management MMC, went to System Tools / Local Users and Groups / Users, and opened the user account (eg. 'router1'). On the Dial-In tab, I enable 'Apply Static Routes' then define the remote networks in the Static Routes window. When the remote router reconnects, the routes are added to the routing table (route print), but if I try to ping them I get a "No Resources" error. Pathping and Tracert also return "No Resources". I can ping the VPN IP (eg. 10.1.1.2), but anything beyond that returns "No Resources". Any ideas? I'm starting to think it's a bug.
September 8th, 2011 11:31pm

Use a router to router VPN link. You can then link the routes to the demand-dial interfaces. The routes are added to the routing table when the VPN connects and the dd interfaces become active. Bill
Free Windows Admin Tool Kit Click here and download it now
September 9th, 2011 3:11am

Hi DejjemTard, Thanks for posting here. You might need to add route entries on RRAS server for reaching other internal subnets . and on client site we should use RRAS’s internal interface address as default gateway in order to let RRAS guides VPN traffics to the correct next router. http://technet.microsoft.com/en-us/library/cc772616(WS.10).aspx#BKMK_5 You may also try to customize VPN client side program by CMAK for updating the route entries : http://technet.microsoft.com/en-us/library/cc786752(WS.10).aspx Thanks. Tiger Li Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
September 10th, 2011 11:37am

Hi, My clients are not Windows clients, they are embedded routers (MikroTik). All routes are set up correctly. It works fine between the two embedded routers. The problem stems from the RRAS side, in fact as I have mentioned in my original post, it works fine if I set up the static routes on the server manually. I'm not sure if I'm missing something on NPS.
Free Windows Admin Tool Kit Click here and download it now
October 31st, 2011 12:22am

As I said before, that is the expected behavior. Routes are only added automatically if you configure the server to accept connections from another router and link the routes to a demand-dial interface. These routes are then stored in the registry. If your remote router connects to a particular demand-dial interface, the appropriate route will be added to the routing table when the remote router connects. If the remote router does not connect to a particular demand-dial interface it is treated as a normal dialup client, not a router, and no return route is set up. All that is set is a host route to the calling machine (not a subnet route). If you think about it, that is the only way it could work. If the server needs return routes for multiple subnets, depending on which router connects, there has to be some way to determine which router is calling in. In RRAS the name of the demand-dial interface is the method used to define the connection. That is why I referred you to router to router (or LAN to LAN) VPN connections. Bill
October 31st, 2011 2:53am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics